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Abstract 

An approach to automate the real-time analysis of 
flight critical health monitoring and system status is 
being developed and evaluated at the National Aero- 
nautics and Space Administration Dryden Flight Re- 
search Facility. A software package was developed in 
house and installed as part of the extended aircraft in- 
terrogation and display system. This design features 
a knowledge-base structure in the form of rules to for- 
mulate interpretation and decision logic of real-time 
data. This technique has been applied for ground ver- 
ification and validation testing and flight test moni- 
toring where quick, real-time, safety-of-flight decisions 
can be very critical. In many cases postprocessing and 
manual analysis of flight system data are not required. 
This paper describes the processing of real-time data 
for analysis and the output format, which features a 
message stack display. The development, construction, 
and testing of the rule-driven knowledge base, along 
with an application using the X-31A flight test pro- 
gram, are presented. 

Nomenclature 


AOA 

angle of attack, deg 

BIT 

built-in test 

EHSV 

electrohydraulic servo valve 

EU 

engineering unit 

FCC 

flight control computer 

FCS 

flight control system 

I/O 

input/output 

ISV 

isolation solenoid valve 

LTEFO 

left trailing edge flap outboard 

LVDT 

linear variable displacement transducer 

MCC 

mission control center 

NZ 

normal acceleration 

OFP 

operational flight program 


RM redundancy management 

TM telemetry 

XAIDS extended aircraft interrogation and dis- 

play system 

Introduction 

Today’s flight control systems are becoming increas- 
ingly complex. The ground testing and flight support 
in the mission control center (MCC) of these systems 
continues to be more time consuming and costly. Two 
problem areas are (1) the collection and processing of 
data and (2) the limited availability of expertise to 
analyze the information. A direct, raw data conver- 
sion in real time into an analyzed result would reduce 
the human-error element in interpreting the data while 
also minimizing the amount of postprocessed data. For 
flight test programs the benefits would result in re- 
duced costs by increasing the sortie rate by minimiz- 
ing the time to detect and analyze problems. An ear- 
lier completion of the test objectives is possible while 
improving the safety-of-flight monitoring and reducing 
support personnel. This was a similar goal to sup- 
port space shuttle flights in the MCC as described in 
reference 1. 

In the MCC traditional real-time displays provide 
only limited information because of the screen size and 
number of terminals (fig. 1). Expert knowledge of the 
system also is required to interpret and analyze the in- 
formation. An alternative approach would allow a large 
amount of data to be processed by using a knowledge 
base which is constructed of rules to formulate conclu- 
sions and decision logic. This technique would auto- 
matically decide for the user what data to present on a 
single message display. The term “rule” as defined in 
this paper is a Boolean expression which may contain 
any relational or logical operators supported by the 
C programming language. This concept provides the 
user the ability to quickly and accurately monitor sys- 
tem parameters such as health, status, configuration, 



and pilot advisory information. The evolution of this 
utility is consistent with the findings of the case study 
reported in reference 2. 

The software application that could satisfy this need 
is a tool such as the extended aircraft interrogation and 
display system (XAIDS) described in reference 3. The 
prototype XAIDS was developed in house and demon- 
strated using the F-18 High Alpha Research Vehicle 
(HARV) iron bird simulation at NASA Dryden. An 
improved version of this package was reprogrammed in 
C language and installed on a UNIX® operating system 
for continued use by the HARV program. This pack- 
age was evaluated in the control room for the X-31A, 
which is described briefly in reference 4. 

The XAIDS package is generic; it can be applied 
to any specific system and is easily portable to any 
UNIX-based operating system. The conversion from 
the F-18 HARV to the X-31A program was easily done. 
The primary differences are the database and the spe- 
cific knowledge-base logic. This paper describes the de- 
velopment, knowledge-base architecture, testing, and 
experience using the XAIDS application for the X-31A 
program. Portions of data from an X-31A flight are 
presented and analyzed using the XAIDS to demon- 
strate the tool’s capabilities and effectiveness. 

XAIDS Messages Design 

The XAIDS messages application is a software pack- 
age which consists of four parts: the knowledge 

base, parser, database, and message display window. 
Figure 2 shows these four parts with the bold borders. 
The database and knowledge-base source files are cre- 
ated for a specific application which is processed by 
a generic parser. The parser expands the knowledge 
base into a stand-alone source code which is compiled 
to form an executable file. This file interfaces with the 
real-time data input stream and updates the XAIDS 
messages display at the input data rate. A detailed 
description of these elements of the system follows. 

Knowledge Base 

The knowledge base contains the rules which trigger 
the messages for the message display. Figure 3 shows 
its general structure. For the application presented in 
this report the knowledge base consisted of three parts: 
preprocessing, parameter typing, and rules computa- 
tion and message generation. 

In the preprocessing section the various tests per- 
formed before further processing include the following: 

1. Verify that the incoming data are live. The live 
data test requires that the flight control computer 

®UNIX is a registered trademark of AT&T Bell Laborato- 
ries, Whippany, New Jersey. 


(FCC) frame counter be incremented each time 
the rules file is called. If the counter is constant, 
a message will be set to indicate a stale data con- 
dition and the routine is immediately exited. 

2. Test for telemetry (TM) dropouts. The TM data 
are tested by checking ground station status words 
to ensure a good signal lock. Data words are tested 
also to ensure no bits are set in positions that 
should always be zero. Finally, selected data words 
are rate checked and compared against a reason- 
able rate limit threshold. If any of these conditions 
occur, the messages are not updated. 

3. Compute the rule update rate. Determine the dif- 
ference in the FCC minor frame counter and con- 
vert to samples/sec. 

4. Determine which FCC channel (1 or 2) is trans- 
mitting the data and display that information in 
a message. 

The parameter typing portion of the knowledge file 
converts desired signals from integer to floating point 
or vice versa. Scale factors are applied for any raw, 
fixed point signals to convert to engineering units 
(EUs). Integers are created from bit masking opera- 
tions to unpack discrete words for later use in the rule 
computations. 

Arithmetic and Boolean expressions are defined in 
the rules-computation and message-generation section. 
Messages are triggered in this section. The rules are 
written so that they all update with each pass through 
the knowledge file. Typical C functions are allowed by 
the parser in these expressions. In addition, customized 
functions are called in this section. 

Parser 

The parser is a program written in C language which 
expands the grammar and structure of the knowledge- 
base file into additional C code for compilation into 
an executable module. It reduces the workload of the 
knowledge-base developer by performing the following 
tasks: 

1. Eliminates explicit data typing 

2. Coordinates message ID tags and message on/off 
logic by appending C code to rules expressions for 
the “else” path to reset messages 

3. Validates references to the data stream 

4. Creates logic to permit data to be input from 
the spreadsheet for testing or from real-time data 
interfaces 
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Database 

A database file contains a symbolic reference of 
the data words set containing the format type. The 
database is used with the knowledge-base file to tell 
the parser how to interpret external data (integer or 
floating point). The integer type also includes packed 
discrete words. Scale factors are included for the raw 
words for conversion to EUs if the scaled words are not 
available from the database. 

Message Display Window 

The XAIDS messages are output to a display win- 
dow in a stack format. Figure 4 shows an example. 
As new messages are added at the top of the stack, old 
messages are pushed down. The mouse is used to scroll 
through the messages should it exceed the window size. 
All messages are automatically appended with the time 
of day as they are added to the stack to provide a log 
of the events. Colored messages help distinguish cate- 
gories of events. Rescinded messages change to white 
for 5 sec before removal from the stack. The older mes- 
sages below are then pushed up to fill the gap in the 
stack. 

The data display stack contains two types of mes- 
sages. One type is a textual character string that pro- 
vides interpreted information. This message is typi- 
cally triggered by single or multiple logical flags. The 
multiple-flag version is used for common messages ap- 
plied to different channels such as quad I/O discretes 
to eliminate duplication. A single message that con- 
tains the embedded channel numbers signifies which 
channels are triggering the message. 

The second type of message is used to output data 
values that continue to be updated. This type is gener- 
ally used in combination with a textual message which 
has been triggered to provide additional information. 
A typical application of this message type is to send a 
data value to the message stack whenever a particular 
limit is exceeded. When that signal is less than the 
limit, the message is removed from the stack. 

An important feature of the XAIDS messages win- 
dow is the option to write a message log file to a disk 
for later printing. Other menu options are available to 
(1) freeze the display, (2) prevent the removal of old 
messages so they can be examined more thoroughly, 
and (3) print the current message stack. 

Knowledge-Base Generation and 
Testing 

The knowledge-base development process consists of 
four steps as shown in figure 5. These steps are (1) 
create a real-time database, (2) develop rules logic, (3) 


test the rules, and (4) install rules with the real-time 
interfaces. 

The database file defines the symbol names and data 
types for the parser. Any real-time data that can be 
monitored by the XAIDS can be added to the database 
file. 

The rules logic are developed from documentation, 
inspection of flight code, system experts, and from sys- 
tem ground and flight testing experience. The logic 
that triggers the messages was developed by answering 
the question, “If event x happens, what information do 
I want to see?” Figure 6 illustrates this logic. A large 
amount of data is processed, but only limited informa- 
tion needs to be displayed at a given time depending 
on the display decision criteria. 

The rules are verified statically from a spreadsheet 
as shown in figure 7. This option is selected by clicking 
the mouse first on the “rules” and then on the test 
boxes. The spreadsheet is automatically loaded with 
all the parameters used in the rules file. The values 
for any parameter may be set from the spreadsheet to 
verify the rules logic. As rules are satisfied, messages 
appear in the XAIDS messages window. 

Finally, the executable XAIDS file is installed on the 
MCC real-time processors. Dynamic testing is done 
by playing back a data file through the XAIDS. The 
messages are compared with known events at specific 
times on the file. The update rate of the rules can 
be determined, and the logic to reject data from TM 
dropouts is tested. 

Rules Development Experience 

The development of the rules for an MCC applica- 
tion of a program like the X-31A involved a moderate 
effort. The construction of rules from packed discrete 
words and flight limit parameters was very mechani- 
cal. Since the knowledge-base developer was not previ- 
ously familiar with the X-3IA FCS, however, consider- 
able time was spent learning the system before trans- 
lation into rules could be done. An inspection of the 
flight code and FCC data was necessary to learn how 
the system worked. The multiple-term expressions and 
nesting of rules such as the actuator redundancy man- 
agement (RM) logic was more difficult to construct. A 
custom routine was written to process a table of 430 
fail codes from the X-31A data words into a charac- 
ter string. Another 200 messages were added to the 
knowledge base to monitor the system health, status, 
flight limits, and pilot advisories. Testing of the rules 
logic using the spreadsheet was very easy and took less 
than one day to complete. 
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Results and Discussion 

The test data presented in this section was obtained 
from a TM tape playback from an X-31A flight. A 
message file was generated from that playback, and 
portions of that data are presented from the preflight 
built-in test (BIT) and events that occurred during 
flight. 

The X-31A preflight BIT program includes an actu- 
ator RM test. To understand the actuator command 
logic for the trailing edge flap logic, refer to figure 8. 
Basically, isolation valve (ISV) discretes from FCCs 1 
and 2 drive actuator 1, and FCC 3 drives actuator 2. If 
either FCC 3 or hydraulic system A fails, a command 
path from FCC 2 is opened to actuator 2 to provide re- 
dundancy. These paths are all tested for each surface 
during the actuator portion of preflight BIT. Table 1 
shows the results of the preflight BIT for the left trail- 
ing edge outboard flap. 

The messages indicate which ISV discretes are failed 
during preflight BIT and whether the actuator or sur- 
face is still functioning. The dash (-) preceding the time 
indicates that the message has been rescinded. This log 
provides the engineer better insight and visibility into 
what preflight BIT is doing and ensures confidence that 
the actuator RM is working as designed. 


To verify if some tests are missing or not working 
properly is easy. The rules are designed as follows. If 
both paths to a given actuator are failed, a message for 
a single link fail is replaced with a message indicating 
that the actuator has failed. If both actuators have 
totally failed for a given surface, the actuator failed 
messages are replaced with a single surface fail mes- 
sage. Should any of these paths fail during flight, the 
appropriate message will immediately be triggered. 

Table 2 shows a portion of the XAIDS messages log 
file from the flight. This segment of the log file con- 
tains a record of surface and flight limits that were 
exceeded. From 14:03:54 to 14:31:05, FCS limits were 
exceeded four times: (1) NZ @ 14:03:54, (2) VANE #1 
Q 14:23:21, (3) AOA @14:31:01, and (4) VANE #1 @ 
14:31:05. Messages were triggered showing what limit 
was exceeded along with the current value of that pa- 
rameter. Other information contained in the log file 
indicates that the pilot requested the spin mode at 
14:15:22. This mode was not engaged, however, be- 
cause the airspeed was greater than 200 knots or the 
airdata was not failed. At 14:27:34 a continuous igni- 
tion command to the engine controller from FCC chan- 
nel 2 was generated because the angle of attack (AOA) 
exceeded 30 deg. 


Table 1. Excerpt from preflight BIT message log file. 


XAIDS Message Log File: 
— = Message off 


11:00:57:252 

11:00:57:402 

11:00:58:102 

11:00:58:352 

11:00:58:352 

11:00:58:552 

11:00:58:902 

-11:01:03:152 

-11:01:03:752 

-11:01:04:202 

-11:01:04:202 

-11:01:04:602 

-11:01:04:812 

-11:01:05:312 


LTEFO ACT #2 IS FAILED 

TOTAL LTEFO SURFACE FAIL; ALL ISV’S ARE DEENERGIZED 
LTEFO ACT #1 FROM C2 DEENERGIZED; Cl STILL FUNCTIONAL 
LTEFO ACT #2 FROM C3 DEENERGIZED; C2 STILL FUNCTIONAL 
LTEFO ACT #2 FROM C2 IS ENERGIZED DUE TO FAILURE OF C3 
LTEFO ACT #1 IS FAILED 

LTEFO ACT #1 FROM Cl DEENERGIZED; C2 STILL FUNCTIONAL 
TOTAL LTEFO SURFACE FAIL; ALL ISV’S ARE DEENERGIZED 
LTEFO ACT #1 FROM C2 DEENERGIZED; Cl STILL FUNCTIONAL 
LTEFO ACT #2 FROM C3 DEENERGIZED; C2 STILL FUNCTIONAL 
LTEFO ACT #2 FROM C2 IS ENERGIZED DUE TO FAILURE OF C3 
LTEFO ACT #2 IS FAILED 

LTEFO ACT #1 FROM Cl DEENERGIZED; C2 STILL FUNCTIONAL 
LTEFO ACT #1 IS FAILED 
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Table 2. Excerpt from flight message log file. 


XAIDS Message Log File: 
— — Message off 


14:03:54:227 
14:03:54:227 
— 14:04:02:767 
-14:04:02:767 
14:15:22:431 
14:15:22:431 
14:15:22:431 
14:15:22:431 
14:15:22:431 
14:23:21:683 
14:23:21:683 
-14:23:30:133 
-14:23:30:133 
14:27:34:965 
14:27:34:965 
-14:28:08:475 
-14:28:08:475 
14:31:01:636 
14:31:01:636 
14:31:05:286 
14:31:05:186 
-14:31:09:636 
-14:31:09:636 
-14:31:10:846 
-14:31:10:846 


* NZ = 1.7 

WARNING - NZ LIMIT EXCEEDED IN R3 MODE; > 1.5G 
WARNING - NZ LIMIT EXCEEDED IN R3 MODE; > 1.5G 
4 NZ = 1.7 

* AIRDATA HAS NOT FAILED 

* VTAS = 385.6 KNOTS 

* VTAS > 200 KNOTS 

SPIN RECOVERY MODE REQUESTED, BUT NOT ENGAGED BECAUSE 
Cl :SPIN RECOVERY SELECT 
4 VANE #1 CMD = 26.4 
*** CAUTION *** VANE #1 CMD >= 26 DEG 
CAUTION *** VANE #1 CMD >= 26 DEG 
+ VANE #1 CMD = 27.7 

* AOA > 30 = 30.4 

C 2 CONTINUOUS IGNITION BECAUSE 
C 2 CONTINUOUS IGNITION BECAUSE 
" AOA > 30 = 30.0 

* AOA > 30 = 30.5 

WARNING - AOA LIMIT EXCEEDED IN BASIC MODE OF 30 DEG 

* VANE #1 CMD = 28.3 

*** CAUTION VANE #1 CMD >= 26 DEG 

WARNING - AOA LIMIT EXCEEDED IN BASIC MODE OF 30 DEG 

4 AOA > 30 = 30.1 

*♦* CAUTION VANE #1 CMD >= 26 DEG 

* VANE #1 CMD = 28.3 


Concluding Remarks 

An in-house development of a rule-based, real-time 
analysis application program for use on a UNIX-based 
operating system was developed and demonstrated at 
the NASA Dryden Flight Research Facility. The mo- 
tivation for this effort was to improve the safety-of- 
flight systems monitoring and to reduce the amount of 
postflight data processing required for both flight and 
ground testing. 

A preliminary evaluation of this concept has proven 
encouraging. Much of the pressure on control room 
personnel for routine safe ty-of- flight monitoring prob- 
ably will be reduced. The XAIDS detected that several 
flight limits were exceeded from the flight portion pre- 
sented. The time tagging of the messages has proven 
usable in providing an automated time log of events 
during the flight which is printed postflight. This log 
helps in determining times for postflight analysis. It 
would be premature to expect to reduce the number 
of control room personnel, but certainly the types of 
parameters that are monitored can be modified which 
more appropriately require human interpretations. 
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Fig. 2. XAIDS message application design. 
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Fig. 3. Knowledge-base execution sequence. 
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c XaldsMessages 

I Log I Print 



Pause 



12:49:05.000 POST STALL IS REQUESTED, BUT NOT ENGAGED BECAUSE 

12:49:05.000 * PITCH STICK CMD <= 1.0 = 0.0 

12:49:05.000 * LANDING GEAR IS NOT UP 

12:49:05.000 * NOT IN BASIC MODE 

12:49:05.000 * COMPRESSOR ROTOR SPEED INVALID 

12:49:05.000 * EST LOAD FACTOR @ 30 AOA > 7.2 = 7.4 

1 2:49:05.000 * MACH > 0.7 = 0.71 



12:49:05.000* COMPRESSOR ROTOR SPEED <84 PERCENT = 0.0 

12:49:05.000 * PRESSURE ALT < 10K FEET = 0 

12:49:05.000 * THRUST VECTORING VANES ARE DISENGAGED 

12:49:05.000 POST STALL ENABLE 

12:48:57.000 LANDING GEAR DOWN 

1 2:48: 1 4.000 TV VANES NOT TO BE USED 

12:48:14.000 ENGINE CORE SPEED FAILED 
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Fig. 4. XAIDS message display window. 
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Fig. 7. Rules verification testing. 
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Fig. 8. Trailing edge flap actuation. 




















